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DETAILED ACTION 

1. This action is responsive to the Applicant's response filed 2/10/2005. 

As indicated in Applicant's response, claims 1-4, 11-14 have been amended, and claims 
10 and 15 canceled. Claims 1-9, and 10-14 are pending in the office action. 

Claim Rejections - 35 USC §103 

2. The following is a quotation of 35 U.S.C 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

3. Claims 1-5, 8-9, and 1 1-14 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Regnell et al., "From Requirements to Design with Use Cases", 3 rd Intl Workwhop on 
Requirements Engineering - Proceeding CAISE '97, June 1997 (hereinafter Regnell), in view of 
Don Heim, "Requirements Management with Use Cases" Software Technology Conference, 
May 1999 ( hereinafter Heim). 

As per claim 1, Regnell discloses a method for simultaneously developing a family of 
complex systems including a plurality of complex systems ( market, countries, standards - pg. 2, 
ch. 2: Context - Note: complex systems including more than one plurality of such systems based 
on market, country or standard reads on family of plurality of systems)having a common 
software architecture platform, the method comprising: 

forming a requirements object model which explains the abstract concepts in terms of 
structured vocabulary (e.g. Fig. 1, pg. 5 - Note: abstract symbols of Tool for representing 
graphically a use case reads on interaction in terms of abstract concepts from a structured 
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vocabulary; CI I, CI 2 ... C14, Component Model - Fig, 2, pg. 5; MSC, Pseudo code - last para, 
Pg- 5); 

developing the use cases based on the set of requirements object model (e.g. Fig. 2, 3, pg. 
5, 6 and related text ), the use cases describing interaction of users with each of the complex 
systems in abstract concepts(e.g. Fig. 3); 

forming functional requirements specifications (FRS) which includes use cases (e.g. 
Functionality Specification - Fig. 1, pg. 5 ) 

But Regnell does not explicitly disclose constructing an initial requirement object model 
(ROM) and an initial set of use cases, a initial FRS; forming an amended ROM, forming 
additional use cases based on the amended ROM; changing the FRS simultaneously with the 
additional use cases, repeating formation of additional use cases, amended FRS and ROM until 
desired use cases have been formed and considered; and obtaining a final ROM once all the 
desired use cases have been considered. 

Making iterative adjustment to graphical representation, model representation data (or 
use case scenarios) like those disclosed by Regnell in order to abstracting or implementing the 
functions as required by design/logical model/specifications (or FRS) so to improve the system 
via such mapping and readjustment of said scenarios was a known concept at the time the 
invention was made because, according to known practice at the time the invention was made, it 
is much preferred to spend resources up front than to ensue rectifying actions and its costly 
consequences when the product is finalized and in use. Regnell discloses how to evolve a design 
from existing stages using evolution and incremental approach via which the consolidation of a 
component specification via a functional distribution model by Regnell using further validation 
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and traceability activities as well as multiple incremental projects (see Regnell, pg. 6-8; three 
increments - pg. 9 ch. 5.1; Evolution, Incremental development - pg. 2); and that already entails 
the need for improving as much as possible during the requirements and pre-design stage. 
Because an use case is a symbolic mirror of a set of functional requirement, the amending of the 
requirement object model along with the amendment of use case scenarios from Regnell would 
have been strongly suggested if not implicitly disclosed. The incremental improvement to a 
model and prototype in complex system with of use cases to effect change to a requirement 
model is evidenced in Heim's teachings. Heim, in a method to capture requirements for an 
information system related to a Patient-Record Military Heath System using Use Cases 
analogous to Regnell 5 s, discloses requirement capture using use cases and incremental changes 
via iteration of scenarios involving creating model and use cases until a suitable prototype can be 
tested (e.g. pg. 8). In case Regnell does not provide successive amending of the ROM 
simultaneously with developing use cases and further repeating the cycle ROM change followed 
by Use Case changes reflecting the changed ROM until a fine-tuned ROM is achieved, then it 
would have been obvious for one of ordinary skill in the art at the time the invention was made 
to implement the ROM by Regnell in light of the incremental approach by Heim, i.e. generating 
an initial set of FR or use cases, then make incremental change to the ROM, use cases and FR, 
with upgrading ROM, Use cases, and FR in response to each increment until a final ROM is 
achieved. Because each use case represents an aspect among more complex business patterns or 
required functionalities of complex families of business logic and making incremental 
improvement to the requirement model in conjunction with new use cases adjustments the final, 
one skill in the art would be motivated to do the above improvement to Regnell' s incremental 
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approach using Heim's teaching because this would increase the chance of weeding out 
imperfection at the requirements stage in the functional model approach by Regnell and 
according to well-known concept of software development, alleviate costly drawbacks during 
later stages of the software lifecycle just as in the traceability costs analysis emphasized by Heim 
or suggested by Regnell. 

As per claim 2, Regnell discloses complex business system and a plurality of developed 
subprojects with coordination of teams aimed as perfecting a model design or models (- pg. 9 ch. 
5.1) and management of the hierarchy of components related to use cases ( e.g. pg. 6-7); hence 
has suggested establishment/organization into teams responsible for requirements and design; 
modeling/validating and for constructing scenarios mapping each assigned section of the 
complex system subcomponents or chapters of a master FRS document. 

Official notice is taken that managing a large software project using developing teams 
with overlapping responsibilities ( members of team being used in other teams), from 
requirement analysis, authoring, to design evaluation, implementation, test scenarios and 
verification, change reviews and traceability analysis, was a well-known concept at the time the 
invention was made. Collaborations between use cases being specified by different authors are 
known in tools like Rational Rose or the likes, thus suggesting overlapping and integrating of 
separately authored Use cases as suggested by Regnell ( see development team -pg. 9 ch. 5. 1) or 
Heim ( see Heim: pg. 8-14). Hence, in case Regnell does not provide overlapping teams for 
authoring requirement specification and modeling of such requirements and for handling specific 
ones of the chapters, it would have been obvious for one of ordinary skill in the art at the time 
the invention was made to provide teams for modeling and for authoring requirements so that 
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members of modeling ( e.g. object model control team) teams cooperate with members of the 
requirement authoring team as taught by common practice as mentioned above. The motivation 
would be to enable repartition of resource/responsibilities and specialization of domain 
knowledge as well as knowledge sharing; hence facilitate supervision and interdependency 
control and/or concurrent development conflict resolution; all of these concepts being integrated 
in to the common overlapping team concept as mentioned above. 

As per claim 3, Regnell does not expressly disclose expressing differences in each 
family of complex system in a component model or plurality of models (see market, countries, 
standards - pg. 2, ch. 2) for each but via projects developed and integrated as from claim 2, the 
establishing of a model for each aspect of a family of complex systems would have been obvious 
because representing one model for a distinct aspect of a family of complex systems would 
enable specific resources to be allotted just to develop and identify the similitude, differences, 
weakness and strengths of what is to be implemented for such distinct member or aspect or 
model, hence increase efficiency, i.e. for the same rationale as mentioned in claim 2. 

As per claim 4, Regnell discloses initial model ( Fig. 1, 2, 3) as specified in claim 1 but 
does not explicitly disclose constructing one from a team, performing the FRS authoring of use 
cases based upon that initial model and performing fine tuning of the use case and the object 
model. 

But it is well evident that when the team, a limitation being obvious by virtue claims 2-3, 
tackles an aspect of the complex requirement system, the steps of 

constructing an initial requirement object model ( Note: creating a initial object model 
and populating changes herein is inherent to every software engineering and modeling), 
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authoring a use case therefor are disclosed as being implicit from the teachings recited in 
claim 1 ( see Regnell: Fig. 1, pg. 5 ; Fig. 2, 3, pg. 5, 6 - Note: It is also noted that the use of Case 
Tool with Use Case for requirement analysis like Rational Rose was a known concept; and 
official notice is taken that authoring in a requirement building process in such tool implicitly 
discloses authoring and creating of model graphical representation; and in light of such Regnell 
has disclosed authoring and building of initial model ); and 

fine tuning of the use cases and refining the model would all have been obvious by virtue 
of claim 1 . 

As per claim 5, Regnell does not explicitly that authoring of use cases is carried out in 
parallel by respective requirement authoring teams. The concept of parallel developing of 
software and concurrent authoring of model specification by more than one developers in 
frameworks such as Regnell' s using UML or Rationale Rose ( Note: it is not perceivable to have 
a computer tool and many teams to support a complex system development as in Regnell' s when 
every stage has to be done in a non-parallel or non-concurrent fashion) was a known concept in 
the art of using Unified Modeling Language or CASE Tools which has been designed for such 
concurrent use of users operating from separate and heterogeneous development environments. 
Hence, Regnell in combination with Heim as set forth in claim 1, has disclosed concurrent 
authoring Use Case in parallel of models by development team members. 

As per claims 8 and 9, in conjunction with the rational of claim 3 for getting a model per 
member of a family, one model for a complex system among family of models. Official notice is 
taken that subclass being derived from more general classes, multiplicities of relationships exists 
between classes in an model entity; and that model components be hierarchized by properties or 
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attributes according to industrial nature a problem, a domain, a business logic or a system 
behavior, in 00 modeling framework or Case Tools like that of Rational Rose was a well-known 
concept at the time the invention was made. Hence, in view of the teachings by Regnell from 
claim 1 and the rationale in claim 3, the limitation of expressing the differences between 
members of a family in the requirements model would have been obvious if not implicitly 
disclosed. 

As per claim 11, Official notice is taken that in a software development, the analyzing of 
a requirement model or models to identify shortcomings and effecting corrective actions to 
improve such shortcomings are well-known concepts at the time the invention was made. The 
limitation of claim 1 1 would be implicitly disclosed in Regnell' s ( in combination with Heim's) 
complex software systems development in light of the validation and traceability tracing 
teachings as mentioned in claim 1 . 

As per claim 12, see claim 1. 

As per claim 13, this limitation is implicitly taught in Regnell or Heim's requirement 
fulfilling process; because if one shortcomings is left unresolved in the scheme of requirement 
validation or verification, the product might not be viable or the purpose of the Requirement 
engineering process as intended by Regnell would be defeated. 

As per claim 14, the limitation as to develop additional use cases simultaneously with 
requirement object models or ROMs has been addressed in claim 1; the limitation that the 
ROMs is thereby formed would also be disclosed based thereupon. 

4. Claims 6 and 7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Regnell et 
al., "From Requirements to Design with Use Cases", 3 rd Intl Workwhop on Requirements 
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Engineering - Proceeding CAISE '97, June 1997; and Heim, "Requirements Management with 
Use Cases" Software Technology Conference, May 1999; as applied in claim 1, and further in 
view of Langlotz, USPN: 6,366,683 (hereinafter Langlotz). 

As per claim 6, Regnell discloses a complex system while Heim discloses that complex 
systems are medical or hospital related application system (pg. 3-4). In a system using modeling 
language similar to the Case Tool to specify an instance of medical application similar to the 
suggestion by Heim, Langlotz discloses the medical system is radiology-related and imaging 
system ( Fig. 1-2). Since medical imaging is but one of many medical diagnostic or hospital 
applications, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to implement one of the business or medical system frameworks as 
suggested by Heim so that a medical imaging or any medical diagnostic application using 
modeling as taught by Langlotz be one of such frameworks, because of the relationships among 
information data as depicted by Langlotz' s medical radiology imaging system would be more 
enhanced for better analysis and reusability when modeling is used. 

As per claim 7, this claim recites the medical imaging limitation of claim 6 in 
conjunction with inter-cooperating teams performing chapters or subsets of the complex FRS as 
addressed in claims 3-5; hence would have been obvious for the same reasons as used in claims 
6, and 3-5 respectively. 

Response to Arguments 
5. Applicant's arguments filed 2/10/05 have been fully considered but they are not 
persuasive. Following are Examiners' remarks. 
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(A) Applicant has submitted that Regnell does not teach amending of the component model 

simultaneously with formation of use cases ( AppL Rmrks, pg. 1 1, 2 para). The use of Case 
tools to produce dynamically the use case based on the perceived set of requirements does not 
stop at a one time implementing use cases strictly in conjunction with a static and unchanging set 
of requirements. Software change due to change to requirement for a plurality of reasons was a 
integral part of complex systems development; and Regnell system is not an exception to being 
subjected to continual demand for changes, one of which due to requirement changes or flaw in 
the designed system demanding recursive adjust to the requirement gathering stage. The 
rejection has pointed to parts of Regnell where incremental adjustments to specifications or use 
cases are prone to happen; and that Evolution, Incremental development (see pg. 2) are part of 
the lifecycle of any product. Heim further has been brought in to evidence via iteration of 
scenarios. Thus it is understood that in order for incremental and iterative improvement be made 
to obtain a final copy of the requirement model, the steps recited as creating a initial ROM, Use 
case set, FRS and repeating adding of upgraded ROM, Use Cases or FRS, would be perceived as 
being integral to Heim's incremental process. Hence, the combination of Regnell and Heim has 
met the teachings from the claim as interpreted by one skill in the art based on broad and 
reasonable construction of the claim language. The argument that a change of a model be 
simultaneous with a adjustment in the Use case seems moot or weightless because a requirement 
model and an use case go hand in hand by the very concept of having a Use case tool to represent 
an aspect of a requirement set. 

(B) Applicant has submitted that Heim does not teach simultaneous formation of additional 
use cases based on the ROM (Appl. Rmrks, pg. 11, 3 rd para). Submitted along with this Action 
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is a sample of a Use Cases tool by Terry Quatrani ( Visual Modeling with Rational Rose and 
UML, 1998), and this is to show that changes to any set of requirements, no matter how small, is 
always and immediately mirrored in the Use case view with corresponding changes to the Use 
case instance ( see Quatrani pg. 157-177); and this attests to the otherwise inherent aspect of the 
parallel mapping of use case(s) and requirement specifics during a given iterative development 
stage as mentioned in Heim's ( or Regnell's) modeling tool; that is, a functional requirement 
change needs to be reflected via adjustments to Use case scenario/instance in order to provide an 
incremental and evolutionary form of improvement towards the final set of requirements, i.e. a 
better product release. Besides, the rejection is a combination of two teachings and Applicant 
has failed to show why the rationale to combine as set forth in the rejection has been 
inappropriate. In response to Applicant picking on each reference taken alone, one cannot show 
nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). 

Conclusion 

6. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
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CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The examiner can 
normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
using) or 703-872-9306 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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